Radio data communication system having means for reducing collisions between contending remote stations

ABSTRACT

A radio based communication system comprises a base station (1) and one or more remote stations (2) each incorporating a radio transmitter and receiver to support communication between the base station and each remote station on a down link and between each remote station and the base station on an up link. Each link comprises a plurality of frames of fixed length divided into a fixed number of slots. The base station includes a base control which transmits control data in a general control slot (GC) in each frame of the down link so as to identify to each remote station a down-setup slot (DSU) in each frame of the down link in which the base station (1) is to announce the transmission of data for it and identify at least one down-transfer slot (DTR) in the frame of the down link in which the data is to be transmitted. The control data further identifies an acknowledgement slot (ACK) in each frame of the down link and an up-setup slot (USU) divided into sub-slots (1/4) in each frame of the up link. Each remote station (2) includes a remote control which transmits a request to transmit data to the base station (1) in any sub-slot (1/4) of the up-setup slot (USU) and receives corresponding data in the acknowledgement slot (ACK) of the down link to identify an up-transfer slot (UTR) in the up link in which it is to transmit data to the base station.

TECHNICAL FIELD

This invention relates to a method of and a system for communicatingdata, in particular communicating data across a radio basedcommunication system.

DISCLOSURE OF THE INVENTION

The present invention consists in a method of communicating data over aradio based communication system between a base station and one or moreremote stations wherein the data is transmitted between the base stationand each remote station in a down link comprising one or more downtime-frames of fixed length, and data is transmitted between each remotestation and the base station in an up link comprising one or more uptime-frames of fixed length, each down frame comprising a fixed numberof down slots at least one of which is a general control slot, at leastone other is a down-setup slot, at least one other is a down transferslot, and at least one other is a down acknowledgement slot, controldata in the general control slot serving to identify to each remotestation the down-setup slot in which the base station is to announce thetransmission of data for it and identify the down-transfer slot or slotsin which said data is to be transmitted, and each up frame comprising afixed number of up sloes at least one of which is identified by controldata in the general control slot as an up-setup slot, at least one otheris an up transfer slot, and at least one other is an up acknowledgementslot, the up-setup slot being divided into a number of sub-slots inwhich each remote station can transmit a request to transmit data to thebase station, and the base station serving to respond to such a requestin a down acknowledgement slot by identifying the up transfer slot orslots in which the remote station is to transmit said data.

The communication of data on the down link and up link involves twophases: a setup phase and a data transfer phase, with a separate slot orgroup of slots, i.e. data channels, being allocated for each phase. Theadvantage of this technique is that the data transfer channel need notbe loaded with data unless the setup phase is successful, and the setupmessages can be very short and hence use very little bandwidth. This isespecially advantageous for transmissions on the up link, since theremote stations, which may be a mobile fleet of users, are necessarilyuncoordinated and will therefore contend for channel capacity.Contention channels, whether operating in Aloha- or CSMA- type modes,have to be operated at low utilisations to avoid instability. Byensuring that contentions take place only between short setup messages,even though the contention time-slots have to be operated at lowutilisation, this has little impact on the overall efficiency of channelusage. The base station responds to a successful up-setup request byallocating capacity on a data transfer channel, which thereby may beoperated in a "scheduled" manner at high utilisation. Similarly, aspackets arrive at a base station to be transmitted to a particularremote station, the base station first executes a down-setup to tell theremote station to monitor the down data transfer channel, then schedulesthe data itself into the down data transfer channel.

Preferably, all data transmitted in the down transfer slot is labelledwith a mobile group label by which it is identified by the remotestation or stations to which it is addressed.

The down-setup slot contains data which identifies the mobile or groupof mobiles to which a message is to be sent, i.e. the mobile group labelallocated to that message. The mobile or mobiles then identify thatmessage simply by reference to the mobile group label as attached todata in one or more down transfer slots until the complete message hasbeen received.

In an alternative embodiment of the invention, however, the down-setupphase may be incorporated in a down acknowledgement slot which the basestation transmits in response to a message from a mobile so that themobile is more rapidly setup to receive a message or reply, therebyshortening the response time. Furthermore, where the reply is so longthat it is divided into a number of separate part messages, each partmessage is adapted so as to include the relevant down setup data for thenext part message, again avoiding the need for a separate down setupphase and thereby shortening the overall response time.

According to a further feature of the invention, any transmission from amobile station in response to a message received from the base stationmay be delayed in time by at least a minimum number of time-slots; andfurther a transmission from the base station in response to a messagereceived from a mobile may be delayed by at least a minimum number ofslots. By this means the radio subsystem of the mobile need not becapable of changing from transmit mode to receive mode very quickly; andthe time available for processing signals and protocol messages in themobile and base station can be maximised.

According to a further feature of the invention, a mobile which does nothave data to send during a given period of time, need only activate itsreceiving and decoding circuits for at least the one down-setup slot ineach frame in which the base station announces the transmission ofmessages for the mobiles, and by this means the power consumed in themobile may be minimised.

Further reductions in power consumption by a factor of "n" may beobtained by the mobile only activating its receive and decoding circuitsfor down-setup slot of every "n'th" frame, provided that the basestation is aware that this action is being followed and sendstransmission announcements for such mobiles only in the appropriateframes.

A further feature of the invention allows the base station to announcechanges to the use being made of slots in the up and down frames usingthe general control slots of the down frame, messages announcing suchchanges not requiring acknowledgement of successful reception by themobiles. For example, the number of up-setup slots divided intosub-slots for mobiles to request the setting-up of a data transferchannel, may be varied depending on the degree of load on the system,this change being announced via the general control slots of the downframe. The number of up-setup slots divided into subslots may be variedin accordance with the number of subslots in which collisions betweenmobile requests take place, and information contained in the requestmessages themselves as to the number of unsuccessful attempts prior tosuccess.

The use of a slotted ALOHA type system allows the use of low-cost,non-duplex radios.

As with conventional radio based communication systems operating with aslotted ALOHA type system, in order to ensure efficient operation of thesystem it is important that the base station and the mobile are inalignment with each other. This is achieved using a synchronisationsignal which is regularly transmitted by the base station and whichallows the mobile to know exactly where it is in a frame.

Preferably, the base station supports radio communication with mobileson at least one or a multiplicity of duplex information bearers, eachcomprising a down link and an up link with a frame structure asdescribed earlier, where the overall structure is announced andcontrolled using the general control slot on one bearer designated amaster bearer, all other bearers being slave bearers; and thesynchronising information transmitted in the down slots of a masterbearer carry information allowing a mobile to rapidly recognise themaster bearer, and the synchronising information of slave bearers carryinformation allowing a mobile to rapidly retune to a master bearer inorder to receive information on the overall use being made of down andup slots on all bearers.

DESCRIPTION OF THE DRAWINGS

The invention will now be described by way of example with reference tothe accompanying drawings, in which:

FIG. 1 shows a schematic representation of a communication system forutilising the present invention; and

FIGS. 2 to 22 show representations of the frames used in the method oftransmitting data in accordance with the present invention, inparticular,

FIG. 2 shows the frame formats,

FIG. 3 shows frame related information (down only),

FIG. 4 shows the protocol layer 2 structure (up and down),

FIG. 5 shows the protocol layer 2 structure (up),

FIG. 6 shows details of the upslot timing,

FIGS. 7a and 7b show arrangements of differential encoding,

FIG. 8 shows slot data encoding,

FIGS. 9a and 9b show the encoding of [1/1] and [1/4] slots,

FIG. 10 shows the interleaving process for [1/1] slot,

FIG. 11 shows the base/mobile data flows,

FIG. 12 shows the radio system implementation model,

FIG. 13 shows the down packet set up,

FIG. 14 shows the down packet transfer,

FIG. 15 shows the protocol layer 3 down link slot contents,

FIG. 16a to 16b shows the protocol layer 3 up slot contents,

FIG. 17 shows the down link packet sementation,

FIG. 18 shows the up link packet assembly,

FIG. 19 shows the message segmentation,

FIG. 20 shows a user/host interaction pattern,

FIG. 21 shows the segmentation of an application message in the systemof FIGS. 1 to 20, and

FIG. 22 shows the segmentation of an application message in analternative body of the invention.

MODE OF CARRYING OUT THE INVENTION

FIG. 1 illustrates a radio based communication system comprising a fixednetwork of radio base stations or sites 1 and one or more mobilestations 2. Each base station has a radio port controller (RPC)associated with it that predetermines the number of radio frequencybearers that it employs. Communication bearers are formed by pairs ofr.f.channels one for transmission of data from the base station 1 tomobile station 2 (downlink) and the other of which is for transmissionof data from the mobile station 2 to the base station 1 (uplink). Eachchannel is therefore simplex.

The communication system operates according to a protocol which isdesigned using a layered approach. Layer 1 defines the basic radioparameters and is not described in any detail herein. In one embodimentof the system, it permits the transmission of data at a rate of 6144bits per second. Layer 2 defines a frame and slot structure that allowsthe bearers to carry time multiplexed data between the base stations andthe mobile stations, and also defines a Forward Error Correction (FEC)scheme. Layer 3 defines the allocation of slots into a selection of datachannels. Data is sent as a connected series of one or more slots calledTransmission Sets (TS) between Radio Multiplexing/Demultiplexing (RMD)means at each end. The RMD means is responsible for any retransmissionof lost slots.

Layer 2 is described in the following sections 1.1 to 1.4. Layer 3 isdescribed in terms of a network overview in the following sections 2.1to 2.10, and in terms of control in the following sections 3.1 to 3.11.

LAYER 2--Data Link Layer

1.1. Frame Format

Each of the bearers transmits data in one or more frames which containsdata as a series of time multiplexed slots, all of which slots are ofthe same length, and are grouped into predefined frames, as shown inFIG. 2.

The frame grouping is defined indirectly by the slot trailers, on alldownlinks. Each downslot trailer (DST) comprises three bits, sync a,sync b and sync c, as shown in FIG. 4 and provides synchronisation forthe individual downslots. A particular sequence of downslot trailersdefines the frame. The sequence of downslot trailers also providesspecific bearer information detailed below.

Uplinks also contain a series of slots that may be transmitted bydifferent mobiles. Each of these mobiles is required to align its upslottransmission to the downslot timing. A simpler upslot trailer (UST) isused on all upslots comprising a single bit sync and a gap, as shown inFIG. 4. This upslot trailer only provides slot synchronisation, andcarries no frame information.

The number of slots in a frame (the frame format) may lie in thefollowing range:

    ______________________________________                                                Minimum   Maximum                                                     ______________________________________                                        Slots/frame                                                                              14         26 slots even numbers only                              Bits/slot 768         768 bits                                                ______________________________________                                    

All bearers from any one base station or site 1 are required to have thesame frame format, with their frames aligned to within 1 bit in order toallow mobile stations 2 to switch between slots on different bearers yetmaintain synchronisation.

Frame alignment between different base sites is optional but desirable.

In principle, the protocol allows for different frame formats atdifferent base sites.

FRAME RELATED INFORMATION (DOWNLINK ONLY)

Frame related information is encoded into all the downlink slot trailers(DST) of a frame, as shown in FIG. 3. Each Radio Port Controller (RPC)transmits one master bearer and up to 3 slave bearers. It is importantthat mobiles can identify slot 0 of the master bearer as quickly aspossible, and this is therefore the major component of frame relatedinformation. However, the complete frame related information uses allthe encoded bits from every slot of a frame. This information contains:

identification of master or slave bearer

identification of slot 0 of a master or slave bearer

a dotting pattern for synchronisation

definition of the frequency offset from a slave to its master.

All the information bits are encoded in the downslot trailers using thesynchronisation codewords defined below. Each trailer contains 3concatenated synchronisation codewords, and each of these codewordsencodes one bit of information N=NSYNC as I=ISYNC. The complete framerelated information can either be viewed as 3 encoded bits per slot, oras three parallel sequences (seq-A, seq-B, seq-C) that repeat once perframe as shown in FIG. 3. FIG. 3 shows the sequences for the minimumframe format of 14 slots and for 4 extra slots for an extended frameformat.

Specifically, the frame related information is defined by the followingcombinations of the encoded bits. Here, the encoded bits are referred toby their sequence letter:

Master/Slave

Master and slave bearers are clearly distinguished in every slot trailerby the combination of seq-A and seq-B. The encoded bits of seq-A andseq-B in each slot of a master have the same polarity, whereas theencoded bits of seq-A and seq-B in each slot (except slot 0) of a slavehave opposite polarity.

Slot 0

The location of Slot 0 can be immediately identified by the combinationof seq-A, seq-B and seq-C:

An [NSYNC] in all three encoded bits identifies slot 0 on a masterbearer An [ISYNC] in all three encoded bits identifies slot 0 on a slavebearer.

Slot 0 location is used to provide frame synchronisation. It can also beused as a confirmation of the frame length, since the frame length,given by the distance between two successive slots 0's, must equal thepredefined value.

Frame Dotting

Frame dotting is introduced to reduce the risk of false frame syncacquisition. Seq-B always contains a dotting sequence:

[ . . . ,NSYNC,ISYNC,NSYNC,ISYNC, . . . ]

This dotting pattern is a mandatory aspect of successful slot and frameacquisition.

Frequency Offset

The frequency offset differs from the other information, because itrequires one encoded bit from several trailers (slot 1 to slot 12inclusive). These 12 encoded bits are shown as F in seq-C of a slavebearer in FIG. 3. Together these encoded bits define the offset fromthat slave bearer to the master bearer (of the same RPC) as a 12 bit 2'scomplement value. The most significant bit is at slot 1, the leastsignificant at slot 12.

1.2 Slot Formats

The full slot length is designed for optimum segmentation of usermessages up to 256 octets long. The protocol also provides an option ofsubdividing one or more upslots into [1/4] subslots, as shown in FIG. 5.These subslots are used on the uplink only to allow for very shortcontention subslots.

The slots and subslots supply the following range of data capacity tolayer 3 of the protocol:

[1/1] slot 510 bits (10 forward error correction FEC blocks of 51 bits)of layer 3 data

[1/4] slot 102 bits (2 forward error correction FEC blocks of 51 bits)of layer 3 data.

Slot Summary

The slot formats are designed to use an exact number of forward errorcorrection (FEC) blocks in all the slot formats. The contents of eachslot are defined in the following components as shown in FIGS. 4 and 5:

    ______________________________________                                        DOWNLINK          UPLINK                                                      ______________________________________                                        Encoded slot data (ESD)                                                                         Padding                                                     Down slot trailer Encoded slot data (ESD)                                                       Up slot trailer                                                               Up slot Gap                                                 ______________________________________                                    

Padding

A minimum of 2 bits of padding is provided on all uplink slots, toprovide initialisation for the differential decoding if required. Nopadding is added to downslots, since a mobile receiver can initialiseits decoding on the trailer of the previous slot. Padding is placed atthe start of each upslot or upsubslot, and the padding bits are filledwith a dotting pattern. The dotting pattern used is:

[01] on upslots

Transmission of this padding is mandatory. The protocol also allows foroptional transmission of further padding by mobiles.

Optional Uplink Padding

Mobiles are permitted to transmit additional padding bits at threepoints:

during the carrier attack time.

during the carrier release time.

in the gap between slots, when the mobile is transmitting successiveslots.

If transmitted, this dotting must be fully synchronous to the encodedslot data. Optional padding can only be added in steps of 2 bits (i.e.an odd number of padding bits is not allowed).

No other data pattern is allowed if this optional dotting is nottransmitted.

Down Slot Trailer

A down slot trailer is transmitted at each slot position. The down slottrailer DST uses three synchronisation codewords that together provide asynchronisation sequence. Each 16 bit codeword can be used normal orinverted, to encode 1 bit of information. Each codeword is used toencode one bit of one of the frame sequences as follows:

Codeword 2:1=NSYNC:0=ISYNC:(one bit of seq-C)

Codeword 1:1=NSYNC:0=ISYNC:(one bit of seq-B)

Codeword 0:1=NSYNC:0=ISYNC:(one bit of seq-A)

The encoding uses the following complementary sync words:

NSYNC (Normal sync): [1100 0100 1101 0111]

ISYNC (Inverted sync): [0011 1011 0010 1000]

All mobile receivers are expected to be able to ocate slots to anaccuracy of +/-10 bits by simple timing from a previous slot where framesync had been acquired.

Up Slot Trailer

An up slot trailer UST is also required at each slot and subslotposition. This contains the single up slot synchronisation codeword:

Codeword 0:USYNC

USYNC (Up sync): [0011 1001 01]

All mobiles are assumed to be able to transmit slots to an accuracy of+/-1 bit by timing (using the down slot trailer to provide slot andframe sync). The up slot trailer UST is designed to providesynchronisation to cover three sources of error:

the mobile timing error of +/-1 bit (just described)

a base timing error of +/-1 bit

0 to 2 bits of propagation delay

This gives a total of 6 bits of timing and propagation errors. Theoverall synchronisation requirement is therefore +/-3 bits.

Up Slot Gap

The up slot gap is used to allow for time division multiplexing andtiming errors on the uplink. This gap allows for the following elements:

30 bits to provide carrier attack/release time (of approximately 5 msecat 6.144 kbps)

6 bits to allow for timing and propagation errors.

The timing diagram for upslots (relative to downslots) is shown in FIG.6. The timing shown is all referred to the base antenna, but the timingreferenced to each mobile antenna will differ depending on its distancefrom the base (i.e. the propagation delay).

All mobiles behave as though their antenna is adjacent to the baseantenna, and transmit relative to their individual received timing,ignoring the possibility that this can be delayed by up to 1 bit fordistant mobiles. Thus each mobile should attempt to align the leadingedge of its [1/1] transmission with the leading edge of the basetransmission. The latest reply then contains a double propagation delayof 2 bits (plus any timing errors) when viewed at the base antenna.

All timing is referenced to the leading edge of the first (mostsignificant) bit of each [1/1] downslot, shown as T between slot N andslot N+1 in FIG. 6. FIG. 6 shows three extreme timing examples with thecarrier attack and release envelopes shown by the overlapping trianglesymbols:

I--The earliest mobile arrival occurs at [-2] bits as a result of atiming error of [-2] bits.

II--The latest mobile arrival occurs at [+4] bits as a result of apropagation delay of [+2] bits plus a timing error of [+2] bits.

III--Any mobile can transmit additional padding, and the third exampleshows the maximum padding on a latest arrival mobile transmission.

Encoded Slot Data

Encoded slot data is an encoded form of the data supplied to/from thelayer 3 protocols.

Differential Coding Implementation

Although the protocol defines differential coding as a layer 1 process,it may be preferable to consider implementation that combine the layer 2processes with differential encoding. This is suggested for ease ofimplementation of the line coding (i.e. the final stage of slot dataencoding). The principle is shown in FIGS. 7a and 7b. FIG. 7a shows thestrict layered approach; FIG. 7b shows an alternative arrangement withseparate differential encoding DIFF CODE for each layer 2 element. Notethat in both cases the differential coding must maintain knowledge ofthe most recent previous transmitted bit.

1.3 Slot Data Encoding

Three encoding processes are applied to the layer 3 data:

Forward Error Correction FEC

Interleaving--INTL

Line Coding (with DC carry-over DC)--LC

The processes are applied as shown in FIG. 8. Each encoding process addsto the layer 3 data, as shown in FIG. 9a for [1/1] slots and as shown inFIG. 9b for [1/4] slots.

Forward Error Correction (FEC)

Forward error correction uses the BCH(63,51) block code for all slotsand subslots.

As the FEC encoding is a block structured process, the slot size hasbeen arranged to contain an integral number of FEC blocks:

    ______________________________________                                        Slot type   Number of FEC blocks                                              ______________________________________                                        [1/1]       10                                                                [1/4]        2                                                                ______________________________________                                    

The FEC code is used to protect the complete layer 3 data (it does notprotect the slot trailer or the padding). The FEC is only used for errorcorrection, and not for error detection.

The FEC code has the following characteristics:

    ______________________________________                                        Code rate:           0.81                                                     Maximum error correction:                                                                          2 errors per block                                       Encoded block size:  63 bits                                                  Information content: 51 bits per block                                        ______________________________________                                    

Interleaving

The FEC blocks will be fully interleaved over the complete slot, foreach slot or subslot as shown in FIG. 10. All the FEC blocks (for eachslot or subslot) are interleaved on a bit-by-bit basis, starting withthe most significant bit of the first block BO, and finishing with theleast significant bit of the last block B9 to produce interleaved blocksIB0 to IB62. This improves the burst error correction properties, bydistributing burst errors across several FEC blocks.

Line Coding

Line coding is used to meet the modulation contraints of simple radios,by maintaining a zero DC content and a low Digital Sum Variation (DSV).This allows the radio modulator to operate with no DC capability and alimited low frequency capability. A 7:8 block code is used that encodes7 bits of input into 8 bits of balanced output, and this operatesdirectly on the interleaved data. The FEC plus interleaving alwaysyields an exact number of line code blocks.

The line coding is required to maintain a zero DC content in thedifferentially encoded data stream. This requires the line coder to usea `history` bit that monitors the differentially encoded output.

DC Carry Over

The line coding can leave a residual DC imbalance at the end of eachcodeword. This imbalance is carried over from codeword to codeword sothat the imbalance is always limited to either +4, +2, 0, -2 or -4 bitsat the end of every codeword. This imbalance must be maintained for alldownlink transmissions and for any sequential uplink transmissions. Itshould only be set to zero at the start of a transmission.

For the continuous downlink transmissions the imbalance at the end ofthe ESD of a slot (or subslot) is carried over to the start of the ESDof the next slot (or subslot), where it provides the initialisationcondition for the line coding. This is designed to maintain the DCcontent in the binary data close to zero under all conditions.

The base therefore only initialises the line coder with a zero imbalanceat (power-up) initialisation. Subsequently the base will always carryover the residual imbalance from slot to slot.

The mobile will initialise every new transmission with a zero imbalance,and is only required to carry over the imbalance when transmittingadjacent sequential [1/1] slots.

1.4 Order of Transmission

The general rule for order of transmission is most significant first.Specifically, data is transmitted in the following order:

i Bits for each octet are transmitted most significant first. This meansbit 7 first, bit 0 last.

ii Octets are transmitted most significant first.

iii A slot is transmitted:

First--optional padding (uplink only)

Second--padding

Third--encoded slot data

Fourth--slot trailer

iv Padding is transmitted most significant bit first.

v Trailers are transmitted most significant codeword first. Eachcodeword is transmitted most significant bit first. Bit 0 is always theleast significant.

vi Slot data is transmitted most significant first.

A network overview with regard to the layer 3 protocols will now begiven.

2. LAYER 3--Network Overview

2.1 Data Transfer Requirements: Logical Model

The Layer 3 protocols are designed to transmit data items in a reliablemanner between the base and mobile. The data items have differentcharacteristics, and are grouped into a set of data channels, as shownin FIG. 11. The following data channels are defined:

    ______________________________________                                                   DOWNLINK    UPLINK                                                 DATA CHANNEL Mode    Data      Mode  Data                                     ______________________________________                                        General Control (GC)                                                                       R       Control   NONE                                           Up-setup (USU)                                                                             R       AC-K/Ctrl C     Request                                  Down-setup (DSU)                                                                           R       Announce  R     ACK                                      Up-Packet transfer                                                                         R       ACK/Ctrl  R     Message                                  (UTR)                                                                         Down-Packet transfer                                                                       R       Message   R     ACK                                      (DTR)                                                                         Registration (REG)                                                                         R       ACK/Ctrl  C     Request                                  ______________________________________                                         R = Reserved slot(s); C = Contention subslot(s)                          

All data channels are bi-directional, except General Control. However,any bi-directional data channel can be used unidirectionally; forexample down-setup can contain general control data, which isunacknowledged.

The General Control Channels is unidirectional. The data will generallybe broadcast, i.e. more than one mobile needs to receive it. It containsessentially fixed data about the particular base, e.g. transmissionfrequencies and slot maps. Once a mobile has received the GC data, it nolonger needs to monitor it as there is no new information. It will bedirected to monitor a setup data channel (specified by the GC data) suchthat it can receive messages. However, the GC data must be continuouslytransmitted so that newly registering mobiles can learn the baseconfiguration.

The up-setup channel USU is bi-directional. An up-setup request is sentfrom a mobile to the base when the mobile wants to send an up-packet.These requests are unidirectional from mobile to base. When the RPCaccepts the up-setup request, an acknowledgement message is sent back tothe mobile.

The down-setup channel DSU is bi-directional. A down-setup announcementis broadcast to a particular group of mobiles to tell them to collect amessage which has become available for them. It is bi-directionalbecause one mobile is always expected to send a positive acknowledgementthat the setup has been correctly received.

Changes in the GC data can be transmitted to mobiles as part of thedown-setup information. It is also possible for the base to effectivelystop sending setup data (for example, by switching transmissions to anon-existent group) in which case the mobiles will time out andautomatically revert to the GC data channel.

Up-packet and Down-packet transfer data channels UTR, DTR arebi-directional. These data channels contain the bulk of the messageinformation from users. The message data is unidirectional, and it isalways positively acknowledged by the receiver. A single user messagemay need to be segmented into several slots. For down-packet the minimumis a single (repeated) acknowledge for the whole message.

The registration channel REG is bi-directional. A registration requestis sent from a mobile to the base when the mobile wants to make itspresence known to the system. Requests are unidirectional from mobile tobase. When the RPC accepts the registration request, an acknowledgementmessage is sent back to the mobile.

2.2 Data Transfer: Physical Model

The logical model, which contains several data channels, must beimplemented physically via a radio link, using the time multiplexedframe and slot structure described earlier.

The characteristics of the radio link are:

time multiplexed data on all bearers.

broadcast mode from base to mobile: all mobiles (within range) areassumed to be able to receive all transmissions from a base.

broadcast mode from mobile to base: more than one base may receive atransmission from a mobile. (In the extreme case a distant mobile mayprevent a local mobile from communicating with its local base: this isco-channel interference).

mobiles are unaware of each other's presence, and can transmitsimultaneously on some data channels, with a risk that they willinterfere with each other's transmissions.

The radio link is organised in a particular way to accommodate thesecharacteristics. Each base station transmits and receives on a small,fixed number of bearers. Each bearer defines a fixed frequency basetransmit link (downlink) and a fixed frequency base receive link(uplink). Low traffic base stations use one bearer (i.e. one uplink andone downlink). Higher traffic base stations can use up to a maximum offour bearers. All link frequencies are fixed.

The usage of each link is defined by the base. It decides thatparticular slots will be used to implement one of the data channel typesdefined above. Slots may be used individually, or be grouped to servethe needs of a particular data channel. The exact configuration may bechanged to suit different traffic patterns, and this may be doneadaptively while the system is operating. However, for an initialunderstanding of system operation, it can be assumed that theconfiguration is constant from frame to frame.

A particular characteristic of the radio uplinks referred to above isthat mobiles can sometimes transmit simultaneously, interfering witheach others, transmissions. The protocols handle this by minimising thenumber and length of unsolicited transmissions from mobiles. A small setof slots are specifically allocated for this contention traffic, and aset of contention handling protocols resolve simultaneous transmissionswhich become corrupted. These contention slots are used for theunsolicited transmissions from a mobile, specifically registration andup-setup.

Outside these contention slots, the mobiles may only transmit inreserved slots. The base station reserves slots for individual mobiles,and tells each mobile when to transmit, so that contention should notoccur for any traffic which the base knows about in advance.

The implementation model comprises a Radio Multiplexer/Demultiplexer RMDin both the base and mobile which multiplexes the various data channelsover the radio bearers. The base RMD is the master, and transmits acontinuous sequence of frames containing the slot structure. The mobilesynchronises to this transmitted data, using a synchronisation patternit detects in the Downslot Trailer as described above.

The RMD uses the slot map to look up which format of slot it is totransmit at each slot output time. The slot map is simply a list of slotnumbers against a slot format. After looking up the format, the RMDfetches data to fill each slot from the appropriate input logicalchannel. For example, if the next slot is a setup format slot, the RMDwill fetch data from the setup data channel output queue.

At the mobile, the RMD needs to know slot formats for the slots it needsto receive and transmit and so uses a slot map in the same way as thebase. Obviously the slot map at base and mobile must be identical inorder for data to be transferred correctly but the slot map cannot bepermanently programmed in to the mobile for reasons of flexibility andadaption as explained above. The solution is for the mobile slot map tobe transmitted--as needed--over the General Control GC and setup datachannels.

System initialisation and reconfiguration are explained below. Briefly,the slot map in the base will be initialised to some predetermined slotassignment IM which will meet some assumed standard mix of traffictypes. The slot map in the mobile will be initialised to expect aGeneral Control channel on slot 0 of the Master Bearer. This GeneralControl channel position is the only mandatory requirement of theconfiguration.

The slot map SM can be adjusted during operation by the Slot AllocatorSA, as shown in FIG. 12. This is driven by a Capacity Manager algorithmCM which uses data provided by the Radio Multiplexer/Demultiplexer RMDto indicate current traffic characteristics. It is anticipated that theadjustment of the slot map is a relatively long term process, comparedwith the slot transmission rate.

2.3 System Operation: Down Packet Transfer

An example of system operation is given for the case of packettransmission from base to mobile. The transmission takes place in twophases, down setup and down transfer. For this example, assume that allinitialisation and registration is complete. In this case, the mobilewill be monitoring transmissions on a down-setup channel. It will havebeen directed to this setup channel by previous general control data,and it is expected to remain on the setup channel until it is directedelsewhere by data transferred over the setup channel. A summary of apossible initial system state is:

single bearer RPC with slot allocation, as shown in FIG. 13,

mobile monitoring down-setup channel 2 (slot 6).

The downlink part of a down-setup channel uses a slot format of type[1/1]. As there is a large population of mobiles all potentiallyavailable to receive messages at any time, there will be a set of manymobiles monitoring this same slot.

In order to transmit a packet to a mobile, the base broadcasts a setupcommand DSUC in this setup channel, as shown in FIG. 13. Each setupcommand contains the mobile-ID and information on where (which bearerand slot) the rest of the message will be transmitted. It also specifiesan identifying label for the forthcoming message, the Mobile GroupLabel, or MGL.

Each down-setup slot can contain several setup commands. For eachdown-setup command, only one mobile will correctly receive and decodeits own mobile ID. This mobile is then expected to transmit anacknowledgement ACK of the setup message to the base, then return itsreceiver to the specified channel, receive the specified slot(s), andextract its message. At this stage the mobile will be receiving datafrom a down packet transfer channel DTR, i.e. data channel 4 (slot 11).

In the down packet transfer phase, as shown in FIG. 14, a set of mobileswill be monitoring this packet transfer channel DTR at any one time:this set is the set of mobiles with packet transfers in progress. Themobile decodes all data in this packet transfer data channel and ignoreseverything except that preceded by the specified MGL. It may have toreceive several slots from this packet transfer channel until itreceives its expected message DTR1, DTR2. Note that the message is onlyidentified by the specified MGL; the mobile ID only appears in thesetup.

As each slot is received, the data is decoded and the complete packet isassembled. An index number is transmitted as part of the fixed overhead,so that the receiver can check that all components of the packet havebeen received. As each slot DTR1, DTR2 is received and decodedcorrectly, the mobile will transmit an ACK for the slot in a reservedsubslot (as specified by the set up).

In addition to the user data transmitted over the packet transferchannel, more control data can be transmitted (in the form of fixedoverheads and control blocks), which can be used to give additionalinformation on how the mobile should proceed.

The end of the packet is defined by the mobile correctly receiving theexpected number of packet slots. The mobile will then automaticallyrevert to monitoring the original set up channel DSU.

2.4 Terminology

The protocol specification uses certain terms in a precise way to definesystem operation. A brief definition of the most important terms isgiven in this section.

Data channel

Refers to the path between mobile and base over which data of aparticular type is transferred.

Phase

The protocol exists as a sequence of phases, e.g.

down-setup

packet transfer

The protocols move from phase to phase as a result of data which istransmitted and external events which occur (e.g. a user deciding toregister). The protocols are in a phase if data of that type is beingtransmitted at any time.

Transmission Set (TS)

The TS is a set of transmissions over a data channel which constitutes acomplete unit of data. For example, a packet transfer transmission setconsists of the individual slot transmissions into which the overallpacket is segmented, and includes the ACKs.

Transmission Set Index (TSI)

An index number which identifies the individual slot transmissionscomprising the total transmission set. For a TS which extends over 4slots, the TSI runs from 1 to 4. The index numbers are re-used and aretherefore not unique across different transmission sets.

Mobile Group

The base may choose to communicate with one mobile, or a set of mobiles.This set (including the case of one mobile only) is called a MobileGroup.

Mobile Group Label (MGL)

An identifying number which uniquely associates a TS with a mobilegroup. The association can be temporary, and a number may be re-usedlater for a different TS or Mobile Group. There is only one MGL whichapplies to each transmission set. It is unique across a base site (andnot just RPC).

State

Used in conventional sense; it completely defines the operatingcondition for the base or mobile at any instant. State transitions occuras a result of internal or external events. Some events may be protocolrelated (e.g. registration), others may be hardware rather than protocolrelated (e.g. low battery in mobile).

States are unique, in the sense that mobile and base will be in one andonly one state at any time. Phases are not unique, in the sense that theprotocols allow (e.g.) packet down-setup and registration to occursimultaneously.

Slot Map

A table which completely defines the current slot format and usage forall slots and all bearers at any point in time. It is RPC specific.

Link

The radio connection uses radio links. One uplink and one downlink isprovided by each bearer. `Link` is preferred to `radio channel` to avoidconfusion with `data channel`.

2.5 System Initialisation

RPC Initialisation

The RPC is initialised with a slot map IM that defines all the neededdata channels. This must always contain a General Control data channelGC in slot 0 of the master bearer, but the rest of the map can beindividually designed. This initial slot map can vary through threemethods:

Extension

Reallocation

Reinitialisation

Extension applies when some slots are unused in the initialconfiguration. Here, these spare slots (even a complete spare slavebearer) can be brought into use.

Reallocation applies when part of the slot map is changed. This involvesclosing down one (or more) data channels and creating a new one on theresulting spare slots.

Reinitialisation applies when the complete slot map is changed. Aspecial control transmission is provided to warn mobiles of an imminentreinitialisation.

Mobile Initialisation

The initial slot map for the Mobile is always defined to contain aControl channel GC on Slot 0 of the Master Bearer. The mobile is alsoprogrammed with the actual frequency of the uplink of radio channel 1,the duplex channel separation, and the permissible range of transmit andreceive radio channel numbers.

The initialisation process from cold is as follows (this process mustalways precede registration on a new RPC):

The mobile scans all of the permissible receive frequencies and recordsthe strongest RSSI values

The mobile selects the link with the strongest RSSI, tunes to it, andtries to synchronise using the Downslot Trailer DST

When it finds the trailer, it decodes the Frame Related Information anduses the contents to determine if this is the master bearer. If it isnot, then the contents will indicate it is a slave bearer at a certainchannel offset from the master. Therefore the mobile can immediatelyretune to the master bearer.

When tuned to the master bearer, the mobile locates slot 0 by using theFrame Related Information as a timing reference. It assumes slot 0contains General Control information, and starts decoding it.

While decoding the slot 0 information, the mobile extracts the ColourCode (which is used to distinguish transmissions from overlapping RPCs)and stores it.

The Colour Code must be present on all future receptions from this RPC,before they can be accepted by the mobile. They must also be used forall transmissions from the mobile to the RPC, and therefore the mobileis only required to store one Colour Code.

After successfully receiving the General Control Data, the mobile shouldhave learned the following elements of the slot map:

i) The registration data channel REG for its primary ID;

ii) The down setup data channel for its primary ID;

iii) The down setup data channel for any secondary IDs (for BroadcastPackets only);

iv) The up setup data channel USU for its primary ID.

Of these, (i) and (ii) are mandatory, but (iii) and (iv) are optional.In particular, the mobile can postpone extraction of (iv) from thegeneral control data channel until it requires to send an up packet.

Once a mobile has learned the slot map, it is not required to monitorthe general control data channel unless it is notified of a change inone of its MGLs. This can happen in the following ways:

i) The specified group MGL is deleted.

ii) A reinitialisation control block (see Section 3) <INIT.0> or<INIT.1> is transmitted from the RPC ordering a group (or groups) ofmobiles to relearn the map. Typically this will be inserted into theappropriate down setup data channel.

The <INIT.0> control block carries an added instruction for the mobilesconcerned to reregister. Both <INIT.0> and <INIT.1> include a MGLspecification, and all mobiles who have been allocated that MGL mustrespond as required. If a general control MGL is specified, then allmobiles must respond. The minimum reuse interval for all MGLs must beretained.

2.6 Radio Constraints on Protocol

Slots can be arranged very flexibly in order to suit particular trafficpatterns, unforeseen changes in traffic pattern, or operational systemrequirements. There are probably several arrangements of slots whichwill suit initial requirements equally well.

The allocation of slots is subject to the following constraints.

i Each mobile operates in half duplex with a turnaround time of at least2 slots, and a response time of at least 3 slots.

The turnaround time is defined as the interval (end-to-start) betweenany two receive or transmit operations. For example, the interval fromreceiving a general control data channel to receiving a down-setup datachannel.

The response time is defined as the interval (end-to-start) between areceive and transmit operation where the mobile (or base) is expected torespond. For example, the interval from receiving a setup, totransmitting an ACK is defined by the response time. The response timeis expected to be dominated by the post detection processing anddecoding of the data.

Single slot, bi-directional data channels will always have anend-to-start interval of 3 slots, in order to satisfy the response timerequirement at both the base and the mobile. However, for multiple slotdata channels it is possible to use a data channel interval of 2 slots,assuming that the data transmitted in the last downlink slot of the datachannel does not require a response to be transmitted in the firstuplink slot (or vice versa).

ii The normal operating state of all mobiles is the low duty cycle (LDC)standby mode, where all relevant down-setup information can be accessedby only monitoring one slot each frame. Mobiles have the option ofentering a Very low duty cycle (VLDC) mode, where all relevantdown-setup information can be accessed by monitoring one slot every [v]frames.

iii The protocol is asymmetric, and it places most complexity into theRPC. All responsibility for the use of the slots resides in the RPC, andthe mobiles are slaved to it. Thus, new features may be introduced atthe RPC without requiring mobiles to be upgraded. Thus, data channeldefinitions other than those described herein may be provided by soleadaptation of the RPC.

2.7 Implementation of Typical System

i All data channels will operate on a fixed pair of radio frequencies.This does not imply a normal duplex pair, but simply implies onetransmit frequency and one receive frequency.

ii The mobile will operate in a half duplex mode which will allow onetransmission period and one reception period each frame interval.

iii If a transmission occupies more than one slot in a frame, the slotsmust be adjacent. This implies that [1/1] slot transmissions (ACKs) froma mobile, when the transmission is confined to an adjacent set of slotsbut the individual ACKs may be transmitted in non-adjacent [1/4]subslots.

iv Mobiles will only be required to process one transfer data channel atany one time.

v Where messages are segmented and transmitted over several slots, thelayer 3 control may only specify the first slot of the transmission,with any following slots being linked using the data channel pointercontained in the slot overhead.

vi An acknowledged transmission will always expect the acknowledgementto be returned within a period of one frame (i.e. in the nexttransmission period of the data channel).

2.8 Dynamic Slot Allocation

The Slot Allocator SA shown in FIG. 12 will allocate slots to bearers asa function of:

available resources

traffic demand.

Over a long timescale (tens of minutes) the slot allocation may need tochange to reflect changes in user demand. For example, during an earlymorning period there may need to be a generous provision of registrationcapacity. Later in the day, this might be more effectively used forpacket capacity. A method of dynamic allocation is therefore preferredto vary the capacity allocated to each data channel, although a fixedslot map could be used with capacity changes being managed by regroupingmobiles using the MGLs.

The Slot Allocator uses the data provided by the RMD in order to modifythe system capacity, e.g. input queue lengths and the number ofcontention failures. The protocol specification supports dynamicmodification of slot allocation, but the particular algorithm to be usedis not part of the protocol. Any Dynamic slot allocation algorithms maybe specified by the system operators.

When the base requires a change to the slot map to be adopted, itnotifies all relevant mobiles by transmitting new control information.This may be done as part of the setup data channel, or by allowingmobiles to timeout so that they retune to the general control channel.

2.9 Retransmissions, ARQ and ACKs

Retransmission Strategy

A retransmission protocol, using error detection based on a 16 bit CRCcode is used, to provide a guaranteed undetected error rate to layer 4.The actual undetected error rate will vary as a function of the radiolink error rate; the CRC defines the absolute worst case.

The protocol primarily operates on a positive acknowledgement basis. Ifthe CRC reports a transmission as error free, the receiver transmits anACK. If an ACK is not received within the expected time, the transmittershould retransmit the data using a selective repeat plus go-back-N (SGB)retransmission strategy.

A negative acknowledgement is also defined (NACK); this can only be usedwhen an expected transmission fails to appear in a predefined slot.

The principle of SGB is that a slot received in error is retransmittedselectively as an interruption in the normal sequence of transmission.If one of these retransmissions is also lost then a go-back-N procedureis applied from that point.

The protocol requires any implementation to always provide a minimum ofone retransmission in all data channels (other than the contention datachannels), so that the go-back-N aspects of the SGB procedure are notmandatory for mobile reception. Mobile transmit procedures are a fullyslave process.

When invoked, the go-back-N procedure starts retransmissions from themissed slot, and includes all subsequent slots. The receiver will retainall slots which have already been successfully received, and only updatethose slots which have been missed.

Successful downslots are always individually acknowledged by the mobile(although one reply may individually acknowledge several slots), so thata retransmission is scheduled in the following circumstances:

an ACK is not received when expected

an ACK is missing from a sequence of ACKs

a NACK is received

a slot is unacknowledged after a timeout.

This retransmission scheme is used for all bi-directional data channels.ACKs are only not used for broadcasts (i.e. when transmissions areaddressed to more than one mobile) such as general control information.

Successful upslots (or subslots) may not be individually acknowledged(this is optional). A mobile can imply success from the subsequenttransmission orders it receives, and mobiles will always receive apositive acknowledgement of the complete message.

ACKs AND NACKs

An acknowledgement event is generated by the transmitter of a message inresponse to some data transmitted back to it by the receiver of themessage. The event may be caused by an explicit or implicit ACK:

explicit means that the receiver transmits a message which means`successful reception` (i.e. the CRC reported no errors);

implicit means that the receiver transmits some other message, but thecontent is such that it also can be inferred as a `successfulreception`.

Explicit ACKs are transmitted from receiver to sender in the form of oneof the dedicated ACK control blocks (<ACK.0>, <ACK.1> and <ACK.2>).Examples of explicit ACKs include normal data transfer, when theacknowledgements specify exactly which slots have been received.

Examples of implicit ACKs are the response to a mobile registration, orthe response to an uplink setup request, where the information contentof the response clearly shows that the initial request has been receivedsuccessfully.

A NACK refers to a negative acknowledgement message; it can be generatedwhen the receiver detects a gap in the received TSI sequence. Note thata NACK cannot be generated when the receiver detects some error within amessage destined for it because the receiver cannot assume any part of areceived message is correct (in particular the mobile ID or the MGL) ifthe CRC validation fails.

The <ACK.1> and <ACK.2> control blocks enable the receiver to ACK orNACK several of the data slots expected or received so far in thetransmission set. The mandatory requirement is for the receiver toacknowledge (ACK) all the successful slots transmitted in the last frameinterval, but unlimited additional ACKs and/or NACKs are allowed. Notethat this rule forces the message recipient to duplicate ACKs inmultiple slot data channels, by reducing the risk of a retransmissionbeing caused by a lost ACK.

2.10 Master Bearer

All RPCs will be required to allocate one and only one bearer to be themaster bearer. The allocated bearer is indicated by the content of theFrame related information. This master bearer will always contain atleast one slot of general control information in slot number 0.

The Master Bearer is expected to be the first point of contact for allmobiles, and it is recommended that master bearers are used by themobile to make any registration decisions (i.e. which is the best base).

Note that master bearers are associated with RPCs. A base site cantherefore have more than one master bearer, if it has multiple RPCs. Thesmallest RPC has only one bearer: by definition this is a master bearer.

3. LAYER 3--Control

3.1 Slot Data

Slot data as shown in FIGS. 15 and 16 consists of:

Slot Overheads SOH

Service Data SVD

Slot overheads contain control information such that the receiver cancorrectly interpret data which will be transmitted to it. The controlinformation is specified in the following forms:

fixed overheads FOH

control blocks (variable overheads) CBK

cyclic redundancy check CRC

The fixed overheads FOH contain a series of independent data elementsthat are all transmitted as part of every slot. This results indifferent arrangements between upslots and downslots and between slotsand subslots.

The control blocks CBK are groups of whole octets which are used tosupply additional control information depending on the currentrequirement. [1/1] slots can contain a variable number of controlblocks. Control blocks have two different lengths specified in number ofoctets. For every control block, the length will be implied by the firstoctet which is a unique identifier. The number of control blocks may bevaried as required, and the number of blocks actually being transmittedin the slot is specified as part of the fixed overheads.

The CRC is included in every slot, and is used for error detection.

Service data SVD contains data originated by the "user" of the radioprotocol described herein.

3.2 Fixed Overheads

The fixed overheads FOH are defined as a bit-packed series of 46elements for [1/1] slots, as shown in FIGS. 15 and 16a, and a bit-packedseries of 22 elements for [1/4] subslots, as shown in FIG. 16b.

    ______________________________________                                        Element               No. of bits                                             ______________________________________                                        DOWNSLOT OVERHEADS                                                            [1/1] slot                                                                    Mobile Group Label MGL                                                                              10                                                      RPC Colour Code CCD   6                                                       ACK mode ACK          8                                                       Length (of Control Blocks) LCBK                                                                     4                                                       Data Channel Pointers DCP                                                                           3                                                       Plus                  1                                                       VLDC                  8                                                       Transmission Set Index TSI                                                                          6                                                       UPSLOT OVERHEADS                                                              [1/1] slot                                                                    Mobile Group Label MGL                                                                              10                                                      RPC Colour Code CCD   6                                                       Not used              8                                                       Length (of Control Blocks) LCBK                                                                     4                                                       Not used              4                                                       Mobile Type TYPE      8                                                       Transmission Set Index TSI                                                                          6                                                       [1/4] slot                                                                    Mobile Group Label MGL                                                                              10                                                      RPC Colour Code CCD   6                                                       Contention counter CTNC                                                                             6                                                       ______________________________________                                    

3.3 Control Blocks

Control blocks will always precede user data, and they are defined inblocks of 8 or 4 octets, with the following structure:

    ______________________________________                                        Octet 7 or 3          Control block                                                                 identifier (CBI)                                        Octets [6 . . . 0] or [2 . . . 0]                                                                   Control block                                                                 information.                                            ______________________________________                                    

There can be as many blocks as necessary in any particular transmission,consistent with the length of the service data and total slot length.

The CBI defines the following information:

Size of total control block (i.e. 8 or 4 octets)

Mandatory/Optional control block

The unique identify (label) of the control block.

Control blocks are defined in two classes, mandatory and optional.Mobiles must respond to mandatory blocks, but the response to optionalcontrol blocks is left to the individual implementation. These could beused for example to implement functions of a particular service which aparticular user group subscribes to: these functions would be ignored byall mobiles not in that group.

3.4 Service Data

Service data SVD will be the unmodified information from the higherlayers. If the information is insufficient to fill an exact number ofslots then the last slot will be filled with the following paddingoctets:

Padding Octets: [00100000]; (ASCII Space)

The recipient of the message must use the Information Length parameterto define the true message length and to eliminate this padding beforereleasing the received packet. In a down packet, the information lengthis contained in the <FNN.0> control block. In an up packet, it iscontained in the <SETUP.0> control block.

3.5 Message Segmentation

The radio system deals with small pieces of data, constrained by thesize of the radio slots. These slots are deliberately chosen to besmaller than fixed network packets for two main reasons:

The radio design uses fixed length slots. Smaller slots are moreefficient given the variable length of user packets;

The radio channel is subject to fading, and longer slots increase therisk of erasure.

This means that the RPC will usually be required to segment or split adownlink packet into a few pieces, and equally to assemble the pieces ofan uplink packet before delivering it to the fixed network.

Examples of segmentation are given in the next sections.

Downlink Packet Segmentation

Downlink PACKETS as shown in FIG. 17 are used with data flowing from topto bottom.

The flow starts with the arrival of the PACKET. This contains individualfields as follows:

    ______________________________________                                        Mobile ID              ID                                                     SN (Sequence Number)   SN                                                     Information Length     INF LTH                                                ______________________________________                                    

The ID is separated into the setup transmission, where it is sent as anelement in the <SETUP.2> control block. The setup also creates a newMGL, which will be used for all later transmissions, assuming the setupis successful.

The second radio slot contains the remaining parameters as elements inone control block, <FNSN.0>. The transmission of additional parameterscan be easily achieved by the use of extra control blocks, provided thatthese are allowed for in the initial setup.

The second radio slot also contains the first octets of information. Therest of the information is sent in the remaining slots of thetransmission set.

The radio slots are of fixed length, so that the final slot requirespadding octets to fill out the slot.

Uplink Packet Assembly

Uplink packets as shown in FIG. 18 are used with data flowing from topto bottom.

The flow starts with the arrival of a series of slots. The contents onlyare considered. The separation of the setup slot and the subsequenttransfer slots are ignored.

The setup slot contains a single Control Block <SETUP.0>. This containstwo parameters:

    ______________________________________                                        Mobile ID             ID                                                      Length of Information INF LTH                                                 ______________________________________                                    

These are used to create a new MGL for reception of the complete packet.

Next the first packet transfer slot arrives. This can contain furthercontrol blocks if necessary, provided that these are allowed for in theinitial setup.

The RPC now links the ID and Length parameters with the sequence numberSN. These are combined with all the information octets INFO, aftersuccessful reception, into a complete packet for immediate delivery.

Note that the last radio slot in this example contains padding octets.This is required to fill the fixed length radio slot.

3.6 Mobile Group Labels (MGL)

MGLs are the short way of addressing a group of mobiles. MGLs allow agroup of just one mobile or more than one up to the entire population,to be defined only once. All subsequent transmissions for this group ofmobiles use the MGL, with a resultant saving in slot addressingoverheads. Even an MGL for a single mobile gives a small efficiency gainas the MGL is shorter than the complete mobile-ID.

The MGL (together with the Colour Code) uniquely labels data to be sentto a group of mobiles at any one time. A small number of MGLs arepredefined as `general control` MGLs. Control information sent withthese MGLs will always be directed at the entire population. All otherMGLs are used for custom associations that are locally defined by theRPC.

If more than one RPC is located at the same base site, there are twooptions for the use of MGLs. In the first option, the RPCs have the samecolour code and share a common pool of MGLs, i.e. any MGL is uniqueacross the RPCs. In the second option, the RPCs each have a differentcolour code and independent pool of MGLs, i.e. the same MGL can existsimultaneously in the different RPCs. The choice between the two optionsis left to the individual implementation.

In all cases, when a set of data has been completely transmitted, theMGL can be reused for a new transmission set, and/or associated with anew group of mobiles. To avoid possible confusion, the MGL must not bereused sooner than a timeout.

The different associations of MGL with mobile group can last for widelydifferent times. The `general control` MGLs are effectively permanent.An MGL that relates to registration information for a group of mobileswill also be relatively long lasting. MGLs that are associated with asingle mobile (e.g. for delivery of a datagram) will last only for thetransmission of a few slots of data, plus any retransmissions.

FIG. 19 shows an input queue of PACKETS, originating from the fixednetwork, which are associated with mobile groups A, B, and C by the RPC.The RPC maintains a queue QUEUE and segmentation SEG process for eachmobile group. The group A process uses MGL-A to identify its setup data,which is common to all members of the group, and contained within thesetup will be separate MGLs for each PACKET A1, A2, and A1 (again). Thesegmentation process is shown as being of different length for eachpacket; each component of the packet will be identified by theseseparate MGLs.

3.7 Transmission Sets

The protocol exists as series of phases, and each phase is made up of aset of slot transmissions to designated mobile groups. The set oftransmissions includes those in the reverse direction whereacknowledgements are required, and any retransmissions needed because oferrors. Examples of transmission sets TS are:

Up transmission plus down acknowledge (e.g. up-packet transfer)

Down transmission plus up acknowledge (e.g. down-packet transfer).

In all cases, every transmission of the set will have the same MGL inthe slot overhead, in the fixed overhead or in a control block, withindividual transmissions being identified by an index number, thetransmission set index (TSI). Retransmissions and acknowledges re-usethe TSI.

A transmission set will usually consist of several slot transmissions.These transmissions can be interleaved with those of a TS for othermobiles or services. Each mobile is responsible for identifying andextracting all transmissions directed to it, using the MGL in the slotoverhead to locate them. Note that a mobile may be interested in morethan one TS. In particular, a mobile must always be prepared to extracta general control TS.

3.8 ACK Modes

The ACK modes are designed to minimise the chances of any acknowledgedtransmission being lost due to fading. The ACK modes follow the approachof the complete protocol by placing most of the complexity into the RPC,and requiring a mobile to remain slaved to the RPC once a transmissionset has begun. In the event of a vital transmission being lost in asequence of communications (e.g. an ACK from the mobile to the RPC for adown packet), the eventual action taken by a mobile is controlled byvarious time-outs. In general, the system is designed so that a fewlosses of a slot or subslot results in them being repeated as part ofthe current transmission set. Repeated failures result in thetransmission set being abandoned, and in this event the complete messagecan be repeated as a new transmission set.

There is an optional mode that is used to increase the reliability ofthe [1/4] subslots that are used by the mobile to acknowledge a downsetup or a down packet, since a loss of this short ACK transmission willcause retransmission of the complete setup or packet. For all moving,and some stationary mobiles, the probability of losing an ACK isminimised by allowing double ACKs to be used whenever the current datachannel requirements allow it. The actual ACK mode for every mobilereply is defined on a slot-by-slot basis in the downslot overheads.

A duplex data channel always specifies the frequencies of the downlinkand the uplink plus the position of the first downslot. The RPC isresponsible for making sure that the size of the upslot and downslotallocations are matched.

Down Packet Example

The same two ACK modes apply to the down packet transfer channel.However, for down transfer channels the ACK mode is defined in the fixedoverhead. At the time of reservation, the base will decide on the basisof current capacity requirements whether ACK mode 1 or 2 will be used.Two examples show the operation:

Assuming that a mobile has received data in the first slot of a datachannel:

with mode 1 (single ACK) specified, the mobile is ordered to send asingle ACK in subslot 0 (or 1 or 2 or 3) of the specified slot.

with mode 2 (double ACK) specified, the mobile is ordered to send twoACKs in subslots 0 and 2 (or 1 and 3).

The intricacies of sharing the upslots between two or more mobiles isleft to the RPC. The mobiles should simply follow the ACK instructionsreceived at all times.

Down Setup Example

A full downslot can carry a maximum of four setup messages to differentmobiles. For setup, the ACK mode is not defined by the fixed overhead,but is defined by the individual setup control blocks. Assuming that thecorresponding upslot allocated for mobile ACKs has its four [1/4]subslots numbered 0 to 3 in order of transmission, the following optionsapply:

The RPC specifies ACK mode 1 (single ACK). The mobiles concerned eachsend a single ACK in one of the [1/4] slots defined by their setupmessages. Typically, this would mean that the mobile addressed in thefirst message sends its ACK in subslot 0, the mobile addressed in thesecond message sends its ACK in subslot 1, etc.

The downslot specifies ACK mode 2 (double ACK)

The mobiles concerned send two ACKs each, in two of the [1/4] slotsdefined by their setup messages. These double ACKs are not sent inadjacent subslots, but in alternate subslots. Typically, this means thatthe mobile addressed in the first message sends its ACKs in subslots 1and 3, etc.

Note that in mode 2, the mobile transmissions are not continuous but arestill confined to a single full slot. This interruption in thetransmission has the advantage of greatly increasing the chances of atleast one ACK being received successfully by the RPC. More generally, amobile can be ordered to acknowledge a multiple slot data channel with avaried selection of ACK modes. This can involve a discontinuoustransmission of several [1/4] slots, although all these transmissionsmust be contained in a single data channel.

3.9 Creation of MGL Assocations

An MGL is associated with the IDs of a group of mobiles using a controlblock such as <MGL.0>. The association uses a subset of the mobile IDbits, so that all members of a group must have identical bits for partof their ID. Thus the groups are not related to user groups, and areonly used for subdivision of the population for control purposes.

3.10 Deletion of MGL Associations

MGLs are not explicitly deleted. Instead, they are implicitly deleted byone of the following methods:

    ______________________________________                                        Completed    All the specified transmissions                                               have been successfully received                                               (i.e. including retransmissions)                                 Replaced     A new MGL association is created                                              which will automatically supersede                                            the previous one                                                 Expired      A transmission set has not supplied                                           any data within a period of time                                              specified by a timer.                                            ______________________________________                                    

"Completed" applies to packet transmission sets (or similar), where theexpected length of the complete TS is specified at setup. The MGLremains in force until all transmissions have been successfully received(including all retransmissions) and terminates immediately afterreception of the final acknowledgement.

"Replaced" could be used when a new arrangement of setup is wanted. Ageneral control TS would be sent announcing the change, i.e. defining anew MGL for the old group IDs, and all mobiles would need to replacetheir old MGL associations (for setup) with new ones. In somesituations, a reinitialisation control block may be used. This does notspecify the new MGLs, but instead directs a specified group or groupsback to the general control to learn their new MGL.

"Expired" could apply when a mobile has missed the general control TSdescribed in `Replaced` above. A little later the mobile would finditself receiving no information. The predefined timeout would cause itto delete its existing MGL association, forcing it to retune to thegeneral control to discover the new MGL.

The up-setup and the registration data channels require special care bythe RPC to ensure that old MGL associations are deleted efficiently. Thepreferred technique is to announce new associations in the appropriatedown setup data channels and also to transmit the current (new) MGLassociations in the up setup and registration data channels on acontinuous but intermittent basis as traffic allows. Up-setup andregistration transmissions from mobiles whose ID is not part of thecurrent mobile group should always be ignored, and the resulting messagefailures will cause the mobile to return to general control.

3.11 Additional MGL Assocations

It is important to note that the control blocks in any TS can be used toprovide information on any TS, including itself. For example, a controlblock could define "MGL crc will contain s slots". This associationwould be sent in the first transmission (TSI=1) on the general controldata channel to define the total length of the control TS.

4. INTERACTIVE SESSION REQUIREMENTS

It may be desirable to connect mobile users into fixed informationsystems, in many cases to access existing applications. The trafficpatterns of this type of use are different from those of the traditionaluse of mobile radio, and are not necessarily well-served by a messageoriented protocol, since the main mode of use is for interactivesessions. In addition, the larger amounts of data which theseapplications may involve, means that the total traffic volume maypredominate even though there may be fewer terminals.

Because of the varying mix of traffic which may arise, it is desirableto have a protocol which can cope with both messaging and interactivetraffic efficiently. However, the exigencies of the radio medium meanthat a connectionless network protocol is still to be preferred to aconnection-oriented one.

FIG. 20 shows diagrammatically a typical pattern of exchangingapplication messages in an interactive session. The session typicallystarts with a user logon request LOGON, and a host response ACK. Theuser then requests REQ, perhaps, a menu screen SCRN which the hostprovides; and this request and screen response may be repeated severaltimes. All the request messages REQ from the user tend to be short,probably less than 250 characters, but the screens SCRN would typicallybe 1000 characters. The main point which emerges from examining thispattern of interaction is that the messages from the terminal user tendto be short, and could be handled by a single packet in a systemaccording to the invention. Where longer messages arise, they aregenerally from the host, and would have to be segmented into several 256octet packets by a transport layer.

The user is generally concerned to see a minimum time between sending arequest to the host (normally this being triggered by his hitting thereturn key) and starting to see a response time of the application. Theuser is also concerned to see the screen filled quickly as well, butthis is less important given that the response time is quick enough togive confidence the system is working.

It is therefore evident that the critical area of network performancedetermining response time is the delay between a packet entering thenetwork from the host and becoming available to the application layersin the mobile terminal, given that the data volume is largest in thisdirection.

The messaging radio protocol outlined in Sections 1 to 3 above, thoughvery efficient, is quite slow for interactive applications. The reasonfor this is shown in FIG. 21.

This shows the segmentation of an application message by a transportlayer TRLR in the host into a sequence of datagrams (of which only thefirst two are shown).

Frame length is assumed to be 12 slots, or 1.5 seconds. It is assumed inthis example that the slot map being operated allocates the second,third, and fourth timeslot of each frame to down transfer, and the firstslot to down setup. 256 Octet packets are assumed to require 5 slotstotal to transfer.

As shown, the first packet PACKET 1 causes a setup in frame 1, thenthree slots of data transfer in frame 2, and two further slots in frame3. Obviously the total time taken to transfer the first packet over theair is 3.375 seconds, of which 2.625 seconds is latent time, firstbetween the setup and first transfer, then between the first and secondtransfer. To this total transfer time must be added an average of half aframe or 0.75 seconds between the arrival of the packet at the base andthe beginning of the first slot. In congested conditions these timeswill be extended by queuing.

When considering the time taken to transfer the entire applicationmessage (i.e. to fill the screen), these times need to be multiplied bythe number of packets involved. Overall, the response times becomeunacceptable for practical remote terminal applications.

By inspecting FIG. 21 it is evident that there are three items to betackled to reduce the time taken to transfer a packet from the base tothe mobile. Generally these concentrate on reducing the variouslatencies in the process.

First, the latencies are mainly determined by the frame length, andtherefore this should be made as short as possible. The nominal framelength previously assumed in the protocol has been 2 seconds (16 slots),but the length is a parameter only needing to be fixed at implementationtime. The shortest practical frame length is 10 slots, but a longerframe may overall be optimum.

Second, the data channels should be made wide enough so that a complete256-octet packet can be transferred in a single frame to eliminate thetime between the first and second transfers indicated in FIG. 21. Eachslot transfers 56 octets, so that 5 slots are needed.

Finally, it is advantageous to introduce a new control mechanism intothe protocol to eliminate the down-setup phase. This can be achieved byarranging that each time a request is made by the terminal application,a class-of-service bit is set which effectively allows the down-setup tobe made in the acknowledgement which the base sends to the terminal oncethe request packet is received correctly.

Thus the down acknowledgement slot includes the terminal ID, a groupmobile label allocated to the response which is to follow from the base,and data identifying the down transfer slots in which the response is tobe transmitted. The base can then go straight into the data transferphase, thereby expediting the delivery of the response and reducing theresponse time.

Further, where the response is long and divided into a number ofseparate messages, each individual message includes the relevantdown-setup data for the next message so that the down-setup phase foreach message is avoided.

FIG. 22 shows the segmentation of an application message in which theabove modifications have been made to improve the response time for theuser.

We claim:
 1. A method of communicating data over a radio basedcommunication system between a base station and a plurality of remotestations comprising the steps of transmitting data between the basestation and each remote station in a down link comprising one or moredown frames of fixed duration; transmitting data between each remotestation and the base station in an up link comprising one or more upframes of fixed duration; dividing each down frame into a fixed numberof down slots at least one of which is a general control slot (GC), atleast one other is a down-setup slot (DSU), at least one other is a downtransfer slot (DTR), and at least one other is a down acknowledgementslot (ACK); providing control data in said general control slot (GC) toidentify for each remote station (2) the down-setup slot (DSU) in whichthe base station (1) is to announce the transmission of data for eachremote station; identifying in a down-setup slot at least onedown-transfer slot (DTR) in which data for each remote station is to betransmitted to each remote station; transmitting data in saiddown-transfer slot to each remote station; dividing each up frame into afixed number of up slots at least one of which is an up-setup slot, atleast one other is an up-transfer slot, and at least one other is anacknowledgement slot; providing control data in said general controlslot to identify for each remote station said up-setup slot; dividingthe up-setup slot (USU) into a number of sub-slots; each remote station(2) wishing to transmit data to the base station (1) transmitting areservation request in one of said sub-slots; the base station (1)responding to each such reservation request from a remote station byidentifying in a down acknowledgement slot (ACK) at least oneup-transfer slot in which each remote station (2) is to transmit data;and each remote station transmitting said data to the base station insaid at least one up-transfer slot.
 2. A method as claimed in claim 1 inwhich the base station (1) transmits data in a down acknowledgement slot(ACK) so as to identify a down transfer slot (DTR) of a following framein which data is to be transmitted to a remote station (2).
 3. A methodas claimed in claim 1 in which the base station (1) transmits data in adown-transfer slot (DTR) so as to identify a down-transfer slot of afollowing frame in which more data is to be transmitted to a remotestation.
 4. A method as claimed in claim 1 in which a group label (MGL)and a transmission set index (TSI) are allocated by the base station todata transmitted in each down-transfer slot to a remote station so as toidentify data in different slots that form part of a larger block ofdata, said remote station identifying said group labels and transmissionset indexes of data in each of said plurality of slots received by itfrom the base station and using said group label and transmission setindex to reassemble and verify the completeness of said larger block ofdata.
 5. A method as claimed in claim 4 in which said group label (MGL)is identified in a down slot.
 6. A method as claimed in claim 5 in whichsaid group label (MGL) is identified in a down-setup slot (DSU).
 7. Amethod as claimed in claim 1 in which there is a delay of apredetermined number of slots between receipt of data in a setup ortransfer slot and transmission of data in a correspondingacknowledgement slot.
 8. A method as claimed in claim 1 in which aremote station (2) whilst it has no data to send, is energised toreceive only the down-setup slot (DSU) in each frame as identified bycontrol data in the general control slot (GC).
 9. A method as claimed inclaim 1 in which the base station (1) uses a limited number of thedown-setup slots (DSU) to transmit to a particular remote station (2),and said particular remote station (2) is energised to receive only thislimited number of down-setup slots (DSU).
 10. A method as claimed inclaim 1 in which the number of up-setup slots (DSU) used is varied inaccordance with the number of remote stations (2) transmitting requests.11. A method as claimed in claim 1 in which synchronisation data (SYNC)is transmitted in every down slot to enable each remote station tolocate each slot within a frame.
 12. A method as claimed in claim 1 inwhich said down link and up link constitutes a master bearer of theradio based communication system, and in which another down link andanother up link structured like those of the master bearer but withoutthe general control slot (GC) constitute a slave bearer, synchronizationdata (SYNC) being transmitted in the down slots of a master bearer toenable a said at least one remote station to recognize the masterbearer, and synchronization (SYNC) data being transmitted in the downslots of each slave bearer to enable a said at least one remote station(2) to retune to the master bearer.
 13. A radio based communicationsystem comprising a base station and one or more remote stations eachincorporating a radio transmitter and receiver to support communicationbetween the base station and each remote station on a down link andbetween each remote station and the base station on an up link, eachlink comprising a plurality of frames of fixed length divided into afixed number of slots wherein the base station (1) includes base controlmeans which transmits control data in a general control (GC) slot ineach frame of the down link so as to identify to each remote station adown-setup slot (DSU) in each frame of the down link in which the basestation (1) is to announce the transmission of data for each remotestation to identify at least one down-transfer slot (DTR) in the frameof the down link in which said data for said remote station is to betransmitted to said remote station, the control data further identifyingan acknowledgement slot (ACK) in each frame of the down link and anup-setup slot (USU) divided into sub-slots (1/4) in each frame of the uplink, each remote station (2) including remote control means whichtransmits a reservation request to transmit data to the base station inany sub-slot (1/4) of the up-setup slot (USU) and receives correspondingdata in the acknowledgement slot (ACK) of the down link to identify anup-transfer slot (UTR) in the up link in which it is to transmit data tothe base station (1).
 14. A method of communicating data over a radiobased communication system between a base station and one or more remotestations comprising the steps of transmitting data between the basestation and each remote station in a down link comprising one or moredown frames of fixed duration; transmitting data between each remotestation and the base station in an up link comprising one or more upframes of fixed duration; dividing each down frame into a fixed numberof down slots at least one of which is a general control slot, and atleast one other is a down-setup slot; providing control data in saidgeneral control slot to identify for each remote station the down-setupslot in which the base station is to announce the transmission of datafor each remote station; dividing each up frame into a fixed number ofup slots at least one of which is an up-setup slot; providing controldata in said general control slot to identify for each remote stationsaid up-setup slot; dividing said up-setup slot into a number ofsub-slots; each remote station wishing to transmit data to the basestation transmitting a reservation request in one of said sub-slots;each remote station receiving said control data in said general controlslot to identify said down-setup slot and said up-setup slot, andthereafter receiving data in said down-setup slot only, at least, untildirected by the base station to again receive control data in saidgeneral control slot.